This fixes issue #1325.  The change is just what @dpvc suggested.  There
is a MWE posted in the issue.

Fix contextFraction.pl with reduceConstants disabled.

propose spelling fix

…coverage badges from README file

Remove badges that are basically broken.

Update to Reaction context

Change all webwork.maa.org links to openwebwork.org

Currently if the display mode is "images", then the student and correct
answer previews don't work.  The images are never actually rendered,
thus the image files are never created, and so the `alt` value is shown
which is the original TeX for the answer.  The reason for this is that
the image generator runs before the post content processor runs.  So
equation images in the problem are rendered, but not those in the
feedback.  That was done because of the hack of inserting the string
`MaRkEr` followed by the image number hash when the image is initially
inserted into the problem text, and then later replacing that with the
alignment styel when the image is rendered. That results in invalid HTML
which `Mojo::DOM` doesn't like.

To fix the issue the `MaRkEr` hack is reworked.  Instead of that string,
a `data-imagegen-alignment-marker` attribute is used whose value is the
image number hash.  Since that is valid HTML, `Mojo::DOM` is fine with
it and leaves it as it is.  So the image generator can now be run after
the post content processor runs, and that renders the images in feedback
as well.

Care is needed for the images in feedback when the
`data-imagegen-alignment-marker` is replaced.  Since the rendered `img`
tag is inside the `data-bs-content` attribute of the feedback button, it
is HTML encoded.  So instead of double quotes, the HTML double quote
escape character (") is used.

The "type" attribute is also replaced for `ol` tags so that this can be
done in a nice way for all of the list types.  Note that although the
"type" attribute is not deprecated for `ol` tags, it is recommended to
use css instead in any case.

…aymode

Fix feedback previews when the display mode is "images".

Replace invalid "type" attribute on `ul` tag in PGML.

When creating a context::Fraction::Parser::Number, use the same
context as the original object instead of the current context.

This fixes issue #1337 with checking if an object created in the
fraction context is equal to a number after the context has changed.
This fix is by @dpvc.

…cro.

The issue occurs with the following MWE:

```
DOCUMENT();
loadMacros(qw(PGstandard.pl MathObjects.pl contextUnits.pl contextFraction.pl));
Context(context::Units::extending('Fraction')->withUnitsFor('length'));
$a = Compute('2*3 cm');
ENDDOCUMENT();
```

Attempting to open the problem with the develop or main branch will
consume all of your server's resources, and eventually the oomkiller
will kill the process.

The changes in this pull request were suggested by @dpvc in an email
communication between @Alex-Jordan, @dpvc, and myself.

This is a possible fix for #1340.  This is now @dpvc's suggested code
from his comment in #1340.

Fix an issue with implied multiplication in the contextFraction.pl  macro.

Since 0 returns false, the logic to ensure Fy was defined was
incorrect, and needs to check Fy is not the empty string.

This causes the macro to fail to load.

Use same context when creating a new context::Fraction::Parser::Number

Fix the legacyFraction.pl init method.

Allow plotting Fy = 0 in plots.

…ssue

Possible fix for the eval issue.

For the following MWE the correct answer is not accepted as correct:

```perl
DOCUMENT();

loadMacros('PGstandard.pl', 'PGML.pl', 'parserCheckboxList.pl', 'PGcourse.pl');

$checkList = CheckboxList(
    [ 50, 51, 52, 53 ], [0],
    labels => 'ABC',
    values => [ 50, 51, 52, 53 ]
);

BEGIN_PGML
Select [`50`].

[_]{$checkList}
END_PGML

ENDDOCUMENT();
```

The problem is that the only correct answer 50 is turned into a
`Value::Real` instead of a `Value::String`.  However, the student answer
is parsed into a `Value::String`, and then the types don't match and it
is marked incorrect.

To fix this explicitly construct the correct answers as strings.

…lly an issue.

The current code passes on the option from the context as a hard coded
zero instead of the actual option value from the context flag.  This
works at this point because this is only used by the parserLogb.pl macro
to make MathQuill not use the base change formula and the option value
it is passing is zero.  However, in the future if a context ever wanted
to enable a MathQuill feature then it wouldn't work.

This moves the error warnings up to immediately after latex or
pdflatex/xelatex (whichever is the latex2pdf program) runs.  This way
these errors are always warned.

When the `TikZ.pm` module was converted the the `LaTeXImage.pm` module
and restructured for PTX output, it resulted in the case that a `pdf`
file is the end result (such as for hardcopy) not having these warnings
issued.

This is to address issue openwebwork/webwork2#2834.

allow empty containers in PGML

fully close most HTML tags in niceTables

don't try to remove a Matrix's only row (or only column)

This changes the feedback buttons in two ways.

1) Use copies of the bootstrap classes to color buttons. This way the
   feedback colors don't get changed by theming on the client side.
   The themes can still modify the actual classes used to change
   the buttons if desired, but the feedback buttons themselves can be
   themed independently of other bootstrap buttons.

2) Create a new feedback class "unknown" to use when showing the
   results of a problem with `$showPartialCorrectAnswers=0`. Currently
   on problems with limited feedback, it can be unclear to the student
   that they actually submitted the answer vs previewed the answer.
   This is accomplished by marking the buttons as incorrect if
   no answer is correct (0% on the problem), and marking them
   as "unknown" which shows a yellow button with a question mark
   in a circle if the problem is partially correct.

`$self` should be `$ans`.  It seems that I changed the third parameter
of the checker from `$self` to the more customary `$ans`, but forgot to
change the usage in the method. Since that is used to skip the adaptive
parameter check when the equivalence message post filter is called, if
you submit an answer that is incorrect, but differs by a constant, and
then submit the correct answer you get the message that "your answer is
equivalent to the previous answer" even though the previous answer was
incorrect, but the current answer is correct.

A missing space in the JSXGraph.pm package causes the `div` for the
JSXGraph image to have invalid attributes. It turns out this is fixed by
the `Mojo::DOM` xml parsing that occurs in the `post_process_content`
phase of the translator, and even if that doesn't fix it most browsers
handle this okay, but HTML validation doesn't like it.  In any case, it
should be fixed.

It should be correct == student.

These are both problems from https://wiki.openwebwork.org/wiki/Problem_Techniques
that demonstrate valid and current techniques in problems that were not
added before for some reason.

Add a `NamedAnswerRules.pg` problem that demonstrates how to use named
answer rules to add buttons to the MathQuill toolbar for the named rule.
This is an updated version of https://wiki.openwebwork.org/wiki/NamedAnswerRules.
With PG 2.21 the way to do so is changing.  So this is needed to
demonstrate the new way to do it.

Add an `AskSage.pl` problem that demonstrates how to use the `AskSage`
method to send a request to a Sage cell server. This is an updated
version of https://wiki.openwebwork.org/wiki/AskSage. Note that this
version of the problem depends on the changes in #1399. Also note that
without #1399 there is no hope for the `AskSage` method in general (so
lets get that merged).

Fix a minor html validity issue with the plots.pl macro.

Fix a typo in the AdaptiveParameters sample problem.

This add the fill_colors option to the add_barplot method.

Feedback button changes.

Add two more problem technique sample problems.

The code that is submitted via the AskSage method no longer works with
the newer versions of Sage and needs to be updated.

Also the public Sage cell server at https://sagecell.sagemath.org/service
no longer accepts public code via its `service` endpoint.  So make the
URL for a sagecell server configurable.

Files for building a sagecell server and deploying it via docker have
been added in the `fsagecell-docker` directory. Instructions for doing
so are in the `sagecell-docker/README.md` file.

Remove the `accepted_tos` parameter from the `AskSage` call.  Just add
the parameter internally, and stop requiring that the author do so.  It
is a meaningless gesture to force the author to do so.  Furthermore, the
docker build is set to not require that parameter.

Also make it so that the `AskSage` method can be called without passing
any arguments, since there are now none that are required.

This was added in #1432, but is causing problems.  If an answer rule is
contained in a `position: relative` parent, then the MathQuill toolbar
ends up being positioned correctly, but is contained inside the
`.problem-content` div, and so you need to scroll to the right to see
it. Note that the `.ww-feedback-container` is `position: relative`.  So
any answer inside a div with that class will have this issue.

An example problem for which the problem occurs is:

```
DOCUMENT();

loadMacros('PGstandard.pl', 'PGML.pl', 'parserMultiAnswer.pl', 'PGcourse.pl');

$ma = MultiAnswer(1, 2)->with(singleResult => 1);

BEGIN_PGML
[<
    Enter 1: [_]{$ma}{5}

    Enter 2: [_]{$ma}{5}
>]{ [ class => 'ww-feedback-container ww-fb-align-middle' ] }
END_PGML

ENDDOCUMENT();
```

Note that this is not a problem when using the problem editor, since the
width of the `.problem-content` div is the same as its parent.  So this
will need to be tested in an actual set.

For now the overflow is left for solutions and hints.  Those won't have
answer rules, and thus will also not have the MathQuill toolbar issue.

So a different way to fix the issue with dark text overflowing into the
dark region outside of the problem will need to be found.  Any ideas?

…overflow

Revert `overflow-x: auto` on `.problem-content` divs.

…ts.pl`.

Although JSXGraph is lenient with this, LaTeX and TikZ are not. So if
you use the `greens` color palette you end up getting the stroke color
for this color in TikZ output. but an aqua marine color for JSXGraph
output.

Here is a MWE for testing this:

```
DOCUMENT();

loadMacros('PGstandard.pl', 'PGML.pl', 'StatisticalPlots.pl', 'PGcourse.pl');

$barPlot = StatPlot(xmin => 0, xmax => 7, ymin => 0, ymax => 10);
$barPlot->add_barplot(
    [ 1 .. 6 ],
    [ 3, 6, 7, 8, 4, 1 ],
    fill_colors => { palette_name => 'greens' }
);

BEGIN_PGML
[<
    [<[@ $barPlot->image_type('Tikz'); @]* [!TikZ bar plot!]{$barPlot}{400}>]
    [<[@ $barPlot->image_type('JSXGraph'); @]* [!JSXGraph bar plot!]{$barPlot}{400}>]
>]{ [ class => 'd-flex gap-3 flex-wrap' ] }
END_PGML

ENDDOCUMENT();
```

I thought I had fixed all of these in my changes to #1374, but I seem to
have missed this one.

Update the `AskSage` method.

Fix the casing of the svg color `MediumAquamarine` in `StatisticalPlots.pl`.

fix logic for when to check answer hints

Any time that a package has certain scripts defined (such as `install`
or `postinstall`), npm now warns about them and tells you to "Run `npm
approve-scripts --allow-scripts-pending` to review, or `npm
approve-scripts <pkg>` to allow."  Note that doing so just adds the
section to the `package.json` file that you see in this pull request.

The package `@parcel/watcher` has an `install` script that rebuilds its
distribution code if an environment variable is set. This script is
harmless, but does not need to be run.

There is no `addToolbarButton` method.  It is `addToolbarButtons`. This
was caused when I changed the MathQuill api, but forgot to change this.

As a result, if an answer uses `parserLogb.pl` the `subscript` button is
not added to the toolbar, and a console log error occurs when this
non-existent method is called.

For a problem to test this with you could use:

```PG
DOCUMENT();

loadMacros(qw(PGstandard.pl PGML.pl parserLogb.pl));

Parser::Logb->Enable;
$n = logb(3, 5);

BEGIN_PGML
Enter [`\log_3(5)`]: [_]{$n}{5}
END_PGML

ENDDOCUMENT();
```

Fix a typo in `mqeditor.js`.

Deny scripts for an npm package.

… or `LaTeXImage`.

This simplifies the checks in the `PGbasicmacros.pl` `image` method that
determine if an image is an instance of a `Plots::Plot`, `WWPlot`, or
`LaTeXImage` package and makes it so that any future package that
derives from one of those will work without further modification to the
`image` method. This uses the `isa` method wrapped in an `eval`.  So if
something is not blessed, the `isa` call will throw an exception, but
the `eval` catches the exception and ignores it returning false.

This is technically not quite as good as using
`blessed $image_item && $image_item->isa('Package::Name')`, but here
should be fine.  The one case that this will now throw an exception for
that the `Scalar::Util::blessed` method would fix is if `$image_item` is
a literal package name that satisfies the `isa` call. For example if
someone were to call `image(WWPlot)` or `image('WWPlot')`. That will now
throw an uncaught exception, since `WWPlot->isa('WWPlot')` will not
throw an exception here and will return true.  So the `insertGraph`
method will be called with the package name `WWPlot`, and that code will
throw the exception because it cannot work with the `WWPlot` package
name. That should not be a real problem though, since no one should do
that. Without this pull request that still wouldn't work, but it would
only give the warning "The file name "WWPlot" does not have an
extension. Every file name used as an argument to alias must have an
extension. The permissible extensions are .gif, .jpg, .png, .svg, .pdf,
.mp4, .mpg, .ogg, .webm, .css, .js, .nb, .csv, .tgz, and .html," but the
problem would still render.  The same would happen for any package name
that derives from one of `WWPlot`, `Plots::Plot`, or `LaTeXImage`.

Use `isa` to determine if a given image is a `Plots::Plot`, `WWPlot`, or `LaTeXImage`.